The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
Commerce may be characterized according to the parties involved. Some types of commerce may be characterized as B2C (or business-to-consumer) if the commerce is between a business and an individual consumer. On the other hand, commerce that involves two businesses is generally referred to as B2B (or business-to-business).
B2B commerce is typically performed electronically. A single electronic communication, such as a communication concerning B2B commerce, invariably involves many types of protocols, such as a protocol used to describe how the content of a communication should be structured or a protocol used in sending the communication to another party. A first party may send an electronic communication to a second party using an application. When an application sends a communication to another party, the application needs to be informed of how to send the communication. As a result, the computer systems of a business may maintain information on (a) which protocols are needed to communicate with other businesses, and (b) how to implement the protocols necessary to communicate with the other businesses.
According to one approach for doing so, a business may store an electronic record for each party with which they wish to communicate. The record identifies all the protocols that are needed to communicate with that party. Further, the record further identifies how to implement each protocol identified by the record. For example, the record may identify a complete set of parameter values for all of the configurable parameters of each protocol identified by the record.
A problem with this prior approach, which is not addressed by the prior art, is that a large number of records may need to be maintained. For example, some businesses may need to communicate with 10,000 other parties; as a result, 10,000 separate records fully describing how to implement any protocol necessary to communicate with that party would need to be maintained. The cost, both in time and resources, to create these 10,000 records would be high, as each of the 10,000 records would need to be retyped from scratch or individually created from a template.
Moreover, another problem experienced by prior approaches concerns how changes are made to the records. If a change that affects multiple records needs to be made, then the change must be made to each of those records individually, thereby requiring an undesirable amount of time and resources to do so. Further, storing 10,000 distinct records also requires an undesirable amount of storage space.